I stopped uploading the single-arch SDKs: get them from the cache instead (note the new key) and we can just upload the three assembled multi-arch SDKs at the end.

Will do!

What am I doing wrong here? https://github.com/marcprux/swift-android-sdk/actions/runs/11022198041/job/30610978833#step:8:13 says:

Cache saved with key: swift-6.0-RELEASE-armv7-ndk-27b-sdk

But then https://github.com/marcprux/swift-android-sdk/actions/runs/11022198041/job/30613448494#step:3:9 says:

Error: Failed to restore cache entry. Exiting as fail-on-cache-miss is set. Input key: swift-6.0-RELEASE-armv7-ndk-27b-sdk

Is cache access restricted to the same job that created it? It was working fine when I was downloading the uploaded artifact.

I've reverted to using upload-artifact/download-artifact to get the SDKs to the assemble-sdks job, but happy to entertain any alternative suggestions you might have for accessing the cache files.

What am I doing wrong here?

You're using the wrong path, compare it to the one I used above. Now that it's just a restore action, maybe you can leave off the path altogether.

Is cache access restricted to the same job that created it?

Of course not, I specifically created an initial toolchain job to populate the caches for the next jobs that actually build the code.

Sounds like you were just working too late, same thing happened with me and the issues I had with working around the latest CMake 3.30. 😉

BTW, I wonder if we should be including the hashes of the build flags and support files in the cache key (as described at https://github.com/actions/cache#creating-a-cache-key). For example, I added "swift-testing" to get-packages-and-swift-source.swift, but since changes to that file don't invalidate the cache, the stale cache files will be used until they are deleted (or age out), resulting in a cached SDK that doesn't reflect the most recent build configuration.

It's a good idea, but since the files in this repo aren't changed that often while the cached SDKs are continually rebuilt because of new Swift snapshot tags, I haven't bothered.

An alternative to this might be to suffix the cache ID with the PR identifier (if any; like with ${{ github.event.pull_request.number || github.event.issue.number }}), which would compartmentalize the cached files for a certain PR. This will trigger an SDK re-build for each pull request (which I want), and it will have the additional benefit of a PR's build not accidentally "poisoning" the canonical main cache if it happens to run between when a new swift devel/trunk/release version is made available and the daily action on main is run.

As an example of why this would be useful, I would like #176 to have triggered a re-build of the SDK because it includes changes to get-packages-and-swift-source.swift, but the action simply re-uses the cached SDK and thereby skips exercising the changes altogether.

I actually like the current behavior of reusing the cached SDKs as much as possible, as it takes almost an hour on the CI to rebuild each SDK, so for most changes that don't require rebuilding the SDK, this is the appropriate default. I simply have to remember to change the cache key anytime I want the SDKs rebuilt, which hasn't been a problem so far. Btw, the PR cache is separate from the scheduled CI cache, so if something is added to the cache in this pull, it won't poison the regular cache.

I suggest you set the cache key in a single place in this pull, say in the first step where the snapshot tag is currently set, write it to $GITHUB_OUTPUT and then use it in all four places where the SDK cache key is now checked after this pull. That way, we can manually change that key string in one place, rather than having to update four.

If you'd like, also add the hash for the Swift script and 11 patches applied to the SDK source to the SDK cache key, so you don't have to manually bump the key each time. You'll have to move cloning this repo in the CI to the first step, so you can hash those files in the now-second step.